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5.  Sifpplomontory  Note* 


1-C1  ^  t  0 


T^'e  Ve'^eral  Aviation  Administration  Is  presently  analyzing  requirement.^  Tor  the 
computer  system  that  will  replace  the  IBM  Model  ,9020  computers,  that  currently 
support  the  en  route  NAS  system,  as  well  as  the  computers  that  support  the  termlnnl 
ARTS  facilities.  As  an  early  Input  to  the  requirements  analysis  effort,  the  KAA's 
Office  of  System  Engineering  Management  requested  a  preliminary  analysis  of  computer 
loads  Imposed  by  near-term  enhancement a  to  the  existing  NAS  and  certain  long-term 
enhancements.  This  report  presents  an  analysis  that  estimates  the  computer  sizing 
requirements  Imposed  by  the  Automated  En  Route  Air  Traffic  Control  (AERA)  system,  n 
possible  long-term  enhancement  to  NAS.  In  order  to  establish  preliminary  AERA 
processor  and  memory  requirements,  two  models  are  presented.  A  simulation  model  of 
the  higher  level  AERA  functions,  such  as  initial  processing  and  progress  monitoring. 
Is  applied  to  the  Washington  Center  to  show  typical  AERA  imposed  processor  loading. 

A  previously  developed  linear  model  of  required  memory  Is  also  applied  to  show  typi¬ 
cal  memory  requirements  resulting  from 

The  models  presented  reflect  a  version  of  AERA  existing  during  December,  1978.  That 
version  of  AERA  did  not  Include  the  recently  developed  concepts  of  strategic  and 
tactical  planning/control.  Additionally,  since  AERA  will  continue  to  evolve  during 
the  development  stage,  requirements  enumerated  must  be  considered  preliminary  in 
nature  and  significant  changes  on  the  estimates  may  be  expected.  Throughout  this 
analysis.  It  Is  assumed  that  there  Is  no  integration  of  the  existing  NAS  functions 
and  the  AERA  functions.  ,^^is  iimslles  that  the  requirements  presented  here  cannot 
be  simply  added  to  estimates  of  nAS  requirements. 
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COHCLOSIOMS 


Bated  on  Che  applicecion  o£  the  preliminaTy  simulation  nwdel  of 
higher  level  AERA  functions  and  of  Che  model  estimating  AERA  memory 
requireawnts  to  Che  Washington  Center,  Che  following  conclusions  have 
been  reached. 

1.  Figure  1  presents  average  processor  utilisation,  in  terms 
of  IBM  9020A  and  DEC  PDF  11/70  seconds  per  second,  if  all  AERA 
functions  generated  during  a  given  ten  second  period  were 
processed  at  the  end  of  the  given  period.  Note  that  these  are 
average  estiisaces  for  processing  required  during  each  ten  second 
period  and,  as  such,  do  not  account  for  peak  utilisation  and 
response  time  considerations.  Relative  to  processor 
requirements  for  the  existing  NAS  (which  is  believed  to  require 
no  more  Chan  three  9020A  seconds  per  second,  for  instantaneous 
aircraft  counts  (lACs)  of  less  Chan  250),  ABIA  will  impose 
significant  processor  requireoiencs, 

2.  A  conservative  estimate  of  AERA  imposed  memory  (buffered 
and  non-buffered)  requireisents  indicated  three  million  bytes  of 
storage  could  accommodate  lACs  of  over  400.  Hence,  it  appears 
Chat  Che  AERA  imposed  memory  requirements  will  not  require 
technology  development  beyond  currently  available  memory  systems. 
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PREFACE 


This  report  presents  «n  analysis  of  the  computer  requirements  imposed 
by  AERA.  In  discussing  the  models  developed  the  author  assumes  that 
the  reader  has  a  basic  understanding  of  the  automation  concepts 
encompassed  by  AERA.  The  reader  may  want  to  see  Mnt-79W0Qj^. 
"Automated  En  Route  ATC  (AERA):  Operational  Concepts,  Package  1 
Description,  and  Issues"  for  an  introduction. 

The  author  wishes  to  thank  Mr.  Richard  W.  Telsch  of  The  MITRE 
Corporation  for  his  contributions  to  this  report.  Mr.  Telsch  had 
previously  developed  the  memory  model  presented  in  the  report  and 
supplied  considerable  background  information  of  the  modeled  AERA 
functions. 
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1»  INTROPPCTIOW 


The  Federal  Aviacion  Admlnistracion  is  presently  considering  the 
replacement  of  its  ATC  computer  systems »  including  the  complement  of 
IBM  Model  9020  computers  which  are  used  to  support  the  present 
enroute  MAS  system.  As  a  part  of  ;:his  effort,  the  Office  of  Systems 
Engineering  Management  is  compiling  a  list  of  computer  requirements 
inq>08ed  by  near-term  and  long-term  improvements  to  the  existing 
system.  These  improvemento,  together  with  the  existing  NAS 
functions,  comprise  a  large  subset  of  the  functions  that  will  be 
supported  at  some  time  by  the  replaciesient  system.  Tlie  primary 
long-term  improvement  considered  in  the  requirements  compilation  is 
the  Automated  Enroute  Air  Traffic  Control  (AERA)  System.  The  purpose 
of  this  report  is  to  establish  preliminary  estimates  of  processor  and 
memory  requirements  that  will  be  imposed  by  AERA. 

The  primary  tool  utilized  in  this  requirements  analysis  was  a 
functional  model  of  AERA  imposed  processing  load.  The  functional 
model  is  a  simulation  of  the  higher  level  AERA  functions  (i.e., 
initial  processing  and  progress  monitor)  and  enables  an  analysis  of 
the  processor  loading  due  to  these  AERA  functions.  The  modeling 
approach  specifically  addresses  the  dynamics  of  the  higher  level 
functions,  but  considers  the  lower  level  computer  functions  such  as 
page  swapping  and  input/output  wait?  as  part  of  these  higher  level 
functions  and  does  not  specifically  model  them.  This  simulation 
model  was  implemented  in  GPSS. 

Required  inputs  and  background  material  for  Che  AERA  functional 
model,  aa  well  as  a  previously  developed  memory  sizing  model,  have 
been  obtained  from  the  AERA  development  effqrC.  More  specifically, 
Che  models  are  based  on  a  simulated  version  of  AERA  existing  during 
Decefld>er,  1978.  Hence,  the  recently  developed  concepts  of  strategic 
and  tactical  planning/control  are  nd't  considered  in  this  analysis. 

It  should  be  noted  that  AERA  is  still  in  early  developmental  stages 
and  as  such  the  estimates  generated  in  this  analysis  are 
preliminary.  However,  these  requirements  estimates  should  be  refined 
to  reflect  a  more  complete  understanding  of  AERA  as  development 
continues . 

The  analysis  in  this  report  assumes  that  the  computer  requirements 
imposed  by  AERA  are  independent  of  requirements  due  to  NAS  and  its 
enhancements.  This  implies  no  integration  of  the  AERA  and  NAS 
functions.  However,  due  to  similaritiea  of  various  functions,  an 
implemented  version  of  AERA  trauld  most  likely  be  integrated  into  the 
NAS.  This  integration  would  result  in  the  deletion  of  duplicated 
functions.  The  implication  to  ejiumeretion  of  requirements  is  that  ' 
the  AERA  requirements  presented  here  cannot  be  simply  added  to  HAS 
requirements  to  obtain  a  realistic  estimate  of  total  requirements 
without  first  examining  the  integration  problem.  Hence,  prior  to 


•  deternlnation  of  total  computer  cequiremaats,  an  erami nation  of  tl^e 
ASRA/HAS  integration  problem  and  its  impact  on  these  ABKA  models  must 
be  made. 

As  will  be  discussed,  the  analysis  of  ABSA  imposed  procass.ot  loading 
did  not  assusw  a  specific  computer  system  architecture.  Therefore, 
eatimatee  for  functional  response  time  were  unable  to.  be  aiade*  As 
computer  system  architectures  are  proposed  as  potential  AITG  comput^o^^ 
replacement  systems,  the  simulation  model  could  be  easily,  revised  to. 
model  specific  architectures  and  to  estimate  processor  utilisation 
and  response  time. 

There  are  two  additional  sections  of  this  report.  Section  Z  of  this, 
report  presents  an  overview  of  the  developed  functional-  model  as  well 
as  a  specification  of  each  individual  function.  Also  ptasonirnd  in 
Section  2  is  a  description  of  a  model  developed  to  determine  the. 
aiemory  requirement  due  to  AERA.  Section  3  preeents  the  results  of 
applying  the  developed  processor  loading  and  meau>ry  models.  Since 
these  sections  document  detailed  technical  analysis,  the  reader  is 
aaaiaMd  to  have  an  understanding  of  the  iORA  design  language  end 
implementation. 


2.  THE  MODELS 


2.1  Processor  Loading  Model 

Figure  2-1  presents  an  overview  of  Che  developed  functional  level 
■odel  used  to  assess  the  processor  loading  due  to  AERA.  The  model  is 
comprised  of  three  basic  components:  a  traffic  generator  and 
simulatori  which  is  responsible  for  simulation  of  a  traffic  load 
through  Che  given  center;  an  AERA  function  generator,  which  generates 
ACTA  functions  (e.g.,  initial  processing,  conflict  resolution)  based 
on  an  aircraft  flight  progress;  and  a  processor  simulator,  which 
simulates  the  performance  of  a  processor  architecture  given  Che 
generated  AERA  function  load.  The  primary  model  inputs  include  ARTCC 
environment  data  and  data  specifying  a  particular  traffic  scenario. 
The  model  could  optionally  receive  as  inputs  real  traffic  data  and/or 
real  AERA  function  data  and,  hence,  not  require  aircraft  simulation 
or  AERA  function  generation.  The  model  output  is  a  set  of 
performance  measures,  such  as  processor  utilization.  These 
performance  measures  will  be  described  in  detail  in  Section  3.  A 
discussion  of  each  model  component  now  follows. 

2.1.1  Traffic  Generator  and  Simulator 


The  traffic  generator  and  simulator  generates  aircraft  and  simulates 
the  aircraft's  flight  through  a  center.  Three  classifications  of  "X. 

aircraft  are  generated  and  simulated:  traffic  overflying  the  center 
(overflights),  traffic  entering  the  center  and  metered  for  landing  at 
a  major  hub  (arrivals),  and  traffic  having  a  departure  point  and 
arrival  point  within  the  center  (intra-center).  Aircraft  departing 
lujor  hubs  within  the  center  are  considered  as  a  part  of  the 
overflight  traffic  classification. 

Figure  2-2  presents  a  flow  diagram  that  describes  the  typical 
aircraft  flight  through  the  center.  Aircraft  flight  is  simulated  by 
determining  for  each  aircraft  the  time  at  which  significant 
pre-detenained  events  (i.e.,  center  boundary  crossing,  descent 
initiation)  occur.  Aircraft  generation  in  each  traffic 
classification  is  random.  Thus,  each  aircraft  is  generated  based  on 
an  exponentially  distributed  time  between  generation,  the  mean  of 
which  is  a  specified  input.  After  the  aircraft  is  generated, 
simulation  of  the  flight  through  the  center  is  begun.  If  the 
aircraft  is  part  of  the  intra-center  traffic  classification,  the 
fliglit  is  initiated  (e.g.,  take-off  and  climb  phases).  If  the 
aircraft  is  an  arrival  or  an  overfli^t,  the  aircraft  is  flown  to  the 
center  boundary.  That  is,  the  point  at  which  the  aircraft  comes 
under  the  direct  control  of  the  center.  Prior  to  this  boundary,  the 
center  has  knowledge  of  the  aircraft  but  not  control.  After  reaching 
the  in-bound  center  boundary,  overfli^ts  are  flown  through  the 
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FIGURE  2-2 

SIMULATION  OF  AIRCRAFT  FLIGBT  THBOUGB  CENTER 


2-3 


center  to  the  boundary  where  the  aircraft  comes  under  the  control  of 
another  center.  Arrivals  and  intra-'Center  aircraft  are  flown  to  the 
point  at  which  they  begin  descending.  These  aircraft  begin  their 
descents  and  are  flown  to  the  approach  boundary  where  they  are  no 
longer  under  the  crntrol  of  the  center.  The  duration  of  fli^t  tiaw 
through  the  center  is  normally  distributed  for  t.ich  traffic 
classification.  The  mean  and  standard  deviation  are  specified  as 
input  data  for  each  of  the  traffic  classifications.  Uhile  this 
simulation  of  aircraft  flight  is  very  simplistic,  it  is  assumed  to  be 
an  adequate  method  of  providing  pertinent  aircraft  flight  information 
to  the  AERA  function  generator.  Flight  information  is  provided  by 
the  traffic  generator  and  simulator  at  various  points  in  the  flight 
profile  (e.g.,  point  of  descent,  crossing  of  center  boundary)  or  when 
queried  by  the  AERA  function  generator. 

2.1.2  abra  Function  Generator 


The  AERA  function  generator  is  responsible  for  the  generation  and 
definition  of  AERA  functions  based  on  individual  aircraft  fli^t 
progress  or  on  predetermined  system  requirements.  After  determining 
that  an  AERA  function  is  to  be  generat^,  the  function  generator  then 
determines  the  associated  amount  of  processing  time  required.  The 
required  processing  time  for  a  function  varies  between  invocations  of 
the  same  ftractions  due  to  the  simulation  dynamics  (e.g.,  actiMl 
traffic,  specific  aircraft  data).  The  required  processing  time  is 
determined  by  algorithms  specified  for  each  of  Che  higher  level  AERA 
functions.  Basically,  the  function  algorithms  determine  which  tasks, 
with  known  deterministic  processing  times,  must  be  dynamically 
invoked  by  Che  AERA  funccon  being  defined'.  After  the  functions  are 
defined,  they  are  queued  at  the  processor  simulation  for  service. 

The  independent  high  level  AERA  functions  considered  in  the  model  are 
enumerated  in  Table  2-1.  In  the  course  of  defining  these  functi<ms, 
the  AERA  function  generator  typically  determines  chat  the  conflict 
prediction  and  conflict  resolution  tasks  must  be  invoked  as  a  part  of 
the  AERA  function.  The  prediction  and  resolution  tasks  are  Chen 
defined  by  specified  algorithms  in  Che  same  manner  as  Che  other  AERA 
functions. 

i 

Bach  of  the  functions  are  now  discussed.  Appendix  A  contains  an 
explanation  of  the  notation  utilised. 

2. 1.2.1  Initial  Processing  Function 

The  initial  processing  functiun  Is  Invoked  for  each  aircraft  at  the 
tisw  when  the  center  receives  iufurmation  that  the  aircraft  will  soon 
enter  its  airspace  or  come  under  its  control.  Relative  to  the 
traffic  simulator,  this  event  occurs  as  soon  as  the  aircraft  is 
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generated.  Figure  2^3  presents  the  definition  of  the  initial 
processing  function.  This  algorithmic  definition  determines  the 
required  processing  time  for  each  specific  invocation  of  initial 
processing.  The  notation  t£  represents  required  processing  time 
due  to  the  use  of  particular  task.  The  total  processing  time  is  the 
sum  of  all  terms  in  all  blocks  of  the  flow  diagram. 

The  initial  processing  function  begins  by  requiring  processor 
resources  for  the  overhead  in  setting  up  the  aircraft  bead  and  for 
absorbing  prior  sector  data  (t^^g^  *  tpgg).  Then  processing  time 
is  required  to  run  the  flight  route  follower,  build  the  vertical 
profile,  and  build  state  segments  (tpgp  *  ^VPR 
processing  time  for  these  taska  are  directly  proportional  to  the 
aircraft's  flight  distance  through  the  center  (d^)*  Processing 
time  for  several  tasks  to  update  displays  and  record  data  (tpp)( 
tn|f  ■t’  tggp)  is  then  required.  If  the  aircraft  is  not  an  arrival 
(i.e.,  overflight  or  intra-center  traffic  classification),  processing 
tisw  for  conflict  prediction  (t(;p)  and  conflict  resolution  (t^g), 
if  necessary,  is  then  required. 

If  the  aircraft  is  an  arrival,  processing  time  is  then  allowed  to 
insert  into  the  metering  schedule  (tuQQ).  The  time  to  process 
state  segment  rebuilding  (tMg),  conflict  prediction  (t^p)  and 
conflict  resolution  (t(^)i  it  necessary,  is  then  determined. 

At  this  point,  the  initial  processing  for  Che  subject  aircraft  is 
complete.  Hwever,  there  is  a  probability  that  other  aircraft  were 
affected  during  the  process  of  inserting  the  subject  aircraft  into 
the  altering  schedule.  For  each  aircraft  affected,  a  metering 
command  is  generated  (tfgjQ),  the  state  segment  is  rebuilt  (tggg), 
and  conflict  prediction  and  resolution,  if  required,  are  invoked. 

2.1.2»2  Handoff  Management  Function 

The  handoff  management  function  is  invoked  each  tiaw  an  aircraft 
crosses  a  center  boundary,  and  hence,  is  handed  off  from  or  to 
another  control  center.  Figure  2-4  presents  the  functional 
definition.  As  can  be  seen,  the  handoff  management  function  is 
deterministic  and  consists  of  only  one  term  (t|g)p). 

2. 1.2.3  Proaress  Monitor  Function 

The  progress  monitor  function  is  invoked  every  three  minutes  by  the 
ABRA  system  for  the  purpoee  of  monitoring  the  progress  of  all 
aircraft.  Figure  2-S  defines  the  algorithm  for  deterining  required 
processing  time  for  this  function. 

Frogress  monitor  starts  by  requiring  processing  time  for  cheeking 
each  of  Che  active  aircraft  (^)  to  determine  if  any  have  deviated 
from  its  prajaetad  flight  profile  (Cm)  and  to  update  the  flight 
plan  billboard  (tpp||).  The  term  n^  ineludas  all  aircraft  under 


FIGURE  2-3 

REQUIRED  PROCESSING  TIME  FOR  INITIAL  PROCESSING  FUNCTION 
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FIGURE  2-5 

REQUIRED  PROCESSING  TIME  FOR  PROGRESS  MONITOR  FUNCTKRI 
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the  control  of  the  center  as  well  as  all  aircraft  that  have  had 
initial  processing  performed  (i.e.,  in-bounds).  Based  on  this 
progress  deviation  check,  the  number  of  aircraft  that  deviate 
sufficiently  enough  that  the  vertical  profile  and  state  segments  must 
be  recomputed  (n^)  is  determined.  For  each  of  these  aircraft, 
processing  time  is  determined  for  the  rebuilding  of  the  vertical 
profile  and  state  segments  for  the  remaining  distance  through  the 
center  (dj^).  Processing  time  required  to  invoke  conflict 
prediction  and,  if  necessary,  resolution  is  then  determined. 

2. 1.2. 4  Clearance  Delivery  Function 

The  clearance  delivery  function  is  invoked  each  time  that  AERA  sends 
a  clearance  to  an  aircraft.  The  function  is  defined  in  Figure  2-6. 
Four  tasks  are  required  for  clearance  delivery:  formulation  and 
delivery  of  the  clearance,  updating  of  the  flight  plan  billboard, 
updating  of  the  clearance  list,  and  recording  of  the  clearance. 

2. 1.2. 5  Periodic  Update  Function 

The  periodic  update  function,  which  is  described  in  Figure  2-7, 
updates  pertinent  flight  information  for  each  individual  aircraft  at 
five  minute  intervals  beginning  after  the  completion  of  initial 
processing.  If  an  aircraft  deviated  suclt  that  the  progress  monitor 
function  was  required  to  rebuild  the  vertical  profile  and  the  state 
segment,  updating  then  occurs  at  five  minute  intervals  beginning  with 
the  time  that  the  last  progress  monicor  function  completed. 

If  the  specific  aircraft  is  an  arrival,  the  fuiicticu  begins  by 
sxamining  the  arrival's  metering  ptogr.±6»  and  issuing  metering 
commands,  if  appropriate  (C)|CG^'  Conflict  prediction  and,  if 
necesaary,  resolution  are  then  invoxed.  In  previous  requirements  for 
conflict  predict,  the  prediction  was  made  for  the  period  of  the 
present  time  through  twenty  minutes  into  the  future.  However,  in  the 
case  of  the  periodic  update  function,  the  prediction  algorithm  is 
taking  the  previous  prediction  results  and  exLending  them  an 
additional  five  minutes  into  the  future.  The  uer  result  is  that  each 
aircraft  always  has  a  minimum  of  fifteen  minutes  of  prediction  and 
not  more  than  twenty  minutes. 

2. 1.2.6  Overhead  Function 

There  are  several  tasks  that  are  invoked  by  the  system  at  specified 
intervals.  For  this  modeling  effort,  these  tasks  have  been  lumped 
together  as  an  overhead  function  invoked  every  ten  sccouds.  The 
function,  defined  in  Figure  2-8,  involves  tasks  for  displays, 
inter facas,  and  data  recording. 
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FIGUKE  2-6 

REQUIRED  PROCESSING  TIME  FOR  CLEARANCE  DELIVERY  FUNCTION 
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FIGURE  1-1 

IBqUXIED  PROCISSUIC  TIW  FOR  PBRltBIC  GFAni  WCtlOII 


2. 1.2.7  Wind  Update  Function 


The  wind  update  function,  as  defined  in  Figure  2-9,  updates  wind 
estimates  every  fifteen  minutes. 

2. 1.2.8  Conflict  Prediction  Task 


As  previously  mentioned,  conflict  prediction  and  conflict  resolution 
are  invoked  by  other  AERA  functions.  However,  since  they  are  rather 
complex,  prediction  and  resolution  are  also  defined  algorithmically. 

Figure  2-10  presents  the  definition  of  conflict  prediction.  The 
function  begins  with  a  term  required  to  set  up  the  prediction  data 
After  the  data  is  initially  set  up,  certain  aircraft  are 
Subjected  to  a  gross  filter  (tQGp)  and  a  final  filter  (tccT^* 

The  number  of  aircraft  submitted  to  the  gross  filter  is  a  function  of 
the  number  of  aircraft  in  the  center  (n^)*  a  typical  fraction  of 
active  aircraft  given  to  the  gross  filter,  and  the  relative  route 
length  (dg/d^).  The  number  of  aircraft  submitted  to  the  final 
filter  is  a  function  of  the  nubmer  of  aircraft  given  to  the  gross 
filter  and  a  typical  fraction  of  active  aircraft  given  to  the  final 
filter.  Additionally,  the  final  filter  term  is  modified  by  an 
expression  indicative  of  the  number  of  state  segments  considered 
during  prediction. 

2. 1.2.9  Conflict  Resolution  Task 


The  conflict  resolution  function  is  defined  in  Figure  2-11.  The 
function  begins  by  requiring  time  for  resolution  overhead  (cgkq). 
After  initial  overhead,  it  can  be  determined  whether  altitude 
resolution  or  path  resolution  is  best  suited  for  the  specific  case  of 
interest.  If  path  resolution  is  decided  upon,  then  path  probe 
(Cpm)  is  invoked.  If  path  probe  is  successful,  then  the  actual 
path  resolution  (tppp)  is  invoked,  alternatively  the  information 
gained  to  this  point  is  saved  and  the  algorithm  begins  again.  Path 
resolution  then  continues  at  the  point  where  altitude  resolution 
begins.* 

Altitude  resolution  begins  by  invoking  the  vertical  profile  builder. 
If  altitude  resolution  appears  to  be  successful  at  this  point,  then 
the  state  segaents  are  built,  otherwise,  the  algorithm  begins  again. 
At  this  point  the  resolution  algorithm  is  reasonably  sure  of  a 
success,  therefore,  the  resolution  plan  is  submitted  to  the  conflict 
prediction  algorithm  to  ensure  that  no  conflicts  still  exist.  If 


*  dsstaaed  processor  times  for  path  probe  and  path  resolution  are 
very  conservative  and  reflect  the  early  state  of  processor  development. 
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required  processing  time  for  wind  update  function 
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FIGURE  2-10 

REQUIRED  PBOCESSIRG  TIME  FOR  CONFLICT  FiSDICTIQN  TASK 
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HGUSE  2-11 

RBQUIRBO  PROCESSING  TIME  FOR  CONFLICT  flESOLOTION  TASK 
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there  ere  etill  conflicts,  the  resolution  elgoritha  begins  egeln, 
otherwise  it  updates  displays,  records  data  and  is  coapleted.  It 
should  be  noted  that  for  the  algorittns  defined,  a  significant  aaount 
of  looping  could  occur.  In  Che  6PSS  model  of  this  algoritm, 
resolution  can  begin  over  again  only  once.  The  model  was  implemented 
this  way  due  to  a  lack  of  data  with  regards  Co  how  the  decision 
probabilities  change  during  the  course  of  the  resolution  algorithm. 

2.1.3  Processor  Simulator 


Once  Che  functions  are  defined,  they  are  queued  at  the  processor  for 
service.  The  processor  simulator  is  responsible  for  the  simulation 
of  processor  system  and  its  interaction  with  the  defined  functions. 
The  simulated  processor  system  may  range  from  a  single  large  CPU  to  a 
system  of  distributed  small  processors. 

Since  the  actual  replacement  processor  Chat  AERA  will  eventually  be 
run  on  was  unknown  at  the  tisie  of  the  analysis,  no  specific  processor 
was  simulated.  Rather,  during  each  simulated  ten. second  eye In,  the 
amount  of  processor  capability  required  to  process  all  functions  in 
the  queum  at  Chat  time  was  determined.  The  determined  amount  of 
processor  capability  was  made  available  every  ten  seconds,  thus 
allowing  all  of  the  functions  in  the  queue  to  be  processed.  Although 
this  procedure  does  not  address  the  question  of  response  tisie,  since 
a  function  waits  no  more  than  ten  seconds  for  service,  it  does  allow 
for  an  esCisuiCion  of  the  amount  of  processor  capability  required 
during  each  ten  second  period. 


2.2  Required  Hemory  Model 

A  linear  model  to  determine  the  number  of  bytes  of  memory  required  by 
AXBA  is  now  presented.  The  model  'relates  the  amount  of  memory  to 
requirements  for  fixed  overhead  tables  as  well  as  to  requirements  for 
dynamic  data  (e.g.,  aircraft  related  data).  The  expression  for 
required  swmory  for  a  complete  center  is; 


'HcBTIBS  •  ♦  MpT  ♦  ligns  *  **AC^"UC  * 

Where: 

MggyTgS  **  Requred  Hemory  in  thousands  of  bytes 
Myg  ■  Memory  Required  for  Teak  Space 

«■  Hemory  Required  for  Fixed  Table  Space 
Mg  •  Memory  Required  iRvirosmwntal  Rate  Space  par  Sactar 
a^  «  Hiaber  of  Sectors  in  the  Center 


2-lS 


^AC  *  Memory  Space  Required  per  Aircraft 
"lAC  *  Number  of  Inatantaaeoua  Aircraft 
°IN  *  Nuaber  of  Inbound  Aircraft 


3.  RBSDLTS 


This  section  presents  the  results  of  the  applicstion  of  the  described 
models  to  the  9020  replacement  problem.  The  first  part  of  this 
section  enumerates  the  environmental  data  used  by  the  model.  The 
environment  data  description  is  followed  by  a  presentation  the  actual 
results  of  the  analysis. 

As  indicated  in  Section  2,  the  functional  level  model  requires 
certain  environmental  data  that  characterizes  a  particular  ARTCC. 

Due  to  the  availability  of  data,  the  Washington  Center  was  selected 
as  the  source  of  all  required  environmental  data. 

Table  3'1  shows  the  aircraft  related  data  representative  of  the 
Washington  Center.  Shown  for  each  traffic  classification  it  the 
percentage  of  the  total  traffic  and  the  average  time  that  an  aircraft 
spends  under  the  control  of  the  center.  It  should  be  noted  that  the 
Washington  Center  overfli^ts  are  primarily  north'south  traffic  from 
or  to  Mew  York.  The  arrivals  which  receive  metering  service  are 
primarily  flights  bound  for  Baltimore-Washington  International, 
National,  and  Dulles  Airports. 

Figure  3-1  presents  the  average  processor  utilization  per  ten  second 
period  imposed  by  the  modeled  AERA  functional  load  for  a  range  of 
instantaneous  aircraft  counts  (lACS).  The  processor  utilization  is 
specified  in  terms  of  9020A  and  PDF  11/70  seconds  per  second.  (The 
9020A  and  PDF  11/70  are  representative  of  computer  technologies  from 
the  mid'sixties  and  mid-seventies,  respectively.  The  PDP  11/70  is 
also  being  used  to  develop  a  test  bed  model  of  the  AERA  system.)  For 
the  curve  shown  in  Figure  3-1,  the  model  was  exercised  for  three 
values  of  lAC  (e.g.,  100,  250,  400)  as  indicated.  It  is  emphasized 
that  the  results  presented  in  Figure  3-1  are  only  average  processor 
utilizations,  and  do  not  address  the  issues  of  response  time  md  peak 
utilization.  From  these  results,  it  is  clear  that  AERA  will  impose 
significantly  larger  processor  requirements  than  the  existing  MAS, 
which  is  certainly  not  requiring  more  than  three  9020A  seconds  per 
second  for  lACS  less  than  250. 

Figure  3-2  presents  the  distribution  of  the  processing  time,  measured 
in  POP  11/70  seconds,  required  to  process  all  AERA  functions  queued 
for  service  at  the  end  of  every  ten  second  period.  These 
distribution  curves,  which  show  the  percent  of  the  total  ten  second 
periods  that  require  specified  levels  of  required  processing  times, 
indicate  a  considerable  range  of  required  processing  times  when  all 
periods  are  examined.  The  distribution  plots  are  presented  to 
emphasise  the  variability  of  amount  of  required  processing  time. 
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figure  3-3  presents  the  results  of  applying  the  described  meaory 
•odel  to  the  Washington  Center  environaent  and  to  an  lAC  range  equal 
to  that  of  the  processor  loading  analysis.  The  memory  analysis 
assumes  a  fixed  table  space  of  20K  bytes,  an  environmental  data  space 
per  sector  of  30K  bytes,  and  38  sectors  in  the  center.  The  dashed 
horisontal  line  indicates  the  required  memory  due  to  the  fixed  tables 
and  the  sector  environmental  data.  The  other  two  lines  represent  a 
nominal  estimate  and  upper  bound  on  the  amount  of  required  memory. 

The  nominal  estisMte  assumed  that  each  aircraft  requires  4K  bytes  and 
that  the  required  task  space  is  300k  bytes.  The  upper  bound  assumes 
an  individual  aircraft  requirement  of  8K  bytes  and  a  task  space 
requirement  of  lOOOR  bytes. 

The  presented  estimates  of  required  memory  are  extremely  conservative 
for  three  reasons.  First,  the  environmental  data  was  sized  for  the 
fairly  complicated  route  structures  of  a  low  altitude  sector.  This 
was  multiplied  by  the  total  number  of  sectors  in  the  center  even 
(houg^  many  sectors  will  essentially  share  the  same  data  (c.g.,  hi^ 
altitude  and  overlying  superhigh  sectors).  Second,  the  individual 
aircraft  storage  reserved  is  large  and  represents  construction  of 
rather  complicated  flight  profiles  for  all  aircraft.  The  8K  byte 
upper  estimate  represents  an  implementation  limit  of  the  AERA 
testbed.  Third,  the  task  space  assumed  that  basically  all  of  the 
code,  which  represents  a  significant  level  of  complexity,  is  resident 
in  main  memory.  It  should  be  noted  that  while  the  memory  estisMtes 
are  large,  modern  memory  systems  are  able  to  accomsodate  the  AERA 
function. 
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Ai.  nmtoppCTiow 

This  appendix  provides  a  definition  of  the  notation  used 
throughout  this  report.  The  enuaeration  of  tenas  is  presented 
in  two  sections:  processing  tia«  terms  and  aiscellaneous  terms. 
The  processing  time  terms  specify  the  tasks,  with  known 
deterministic  processing  time,  that  comprise  the  AERA 
functions.  The  miscellaneous  terms  specify  the  required 
variables  used  in  the  isodels. 

A2.  PgQCBSSlHG  TIME  TERMS 


A  list  of  the  processing  time  terms  follows.  The  list  includes 
a  definition  of  the  term  and  the  estiswted  value  of  the  term  in 
PDF  11/70  Billiseconds.  The  source  of  the  term  values  is  the 
AERA  testbed  development  effort.  In  some  case,  the  values  of 
the  term  have  been  roughly  aessured  from  execution  of  existing 
software  code.  The  measurements  were  obtained  from  the  AERA 
simulation  software  running  on  the  MITRE  IBM  370-148.  The 
timing  estimates  were  then  converted  to  PDF  11/70  execution 
times  using  an  IBM  370/148:  POP  11/70  execution  time  ratio  of 
approxisMtely  1:1  as  determined  by  A.  Macker  (MITRE  Memorandum 
M46-M0592,  October  20,  1977).  In  cases  where  software  is  not 
existing,  engineering  estimates  have  been  made  of  the  values. 
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TERM  DEPIHITIOM  VALOI 

ilWTm*) 


‘ABC 

Time  required  for  overheed  in  ebsorhing 
flight  plen  and  setting  up  aircraft  bead 

20 

‘ado 

Time  required  for  automatic  data  block 
offset  per  aircraft 

0.3 

‘bss 

Time  required  to  process  state  seysents 
given  altitude  and  speed  commands  exist 
for  a  unit  length*  route 

1 

‘CCT 

Time  required 

for  final  conflict  test 

5 

‘CGF 

Time  required 

for  gross  conflict  filter 

2 

‘CLU 

Time  required 

to  update  clearance  list 

3 

‘CCR 

Time  required 
eleetenee 

to  fonsulate  and  deliaer 

10 

‘cp 

Time  required 

task 

for  conflict  prediction 

datarmined 

dyAamicaliy 

‘CR 

Time  required 
task 

for  conflict  resolution 

datarmined 

dynamically 

‘CRO 

Time  required 

for  resolution  overhead 

300 

‘CTO 

Time  required 
overhead 

for  conflict  test 

30 

‘drc 

Time  required 
eleareece 

for  record  delivered 

o.s 

‘SRM 

Tima  requited 

img 

for  mlscelleMoue  rueord*^ 

0.3 

Time  required 

to  record  a  profile 

3 

‘■it 

Time  required 

to  record  track  data 

0.2 

*mift  •*  «M  ttil« 


TERM 


DBFimTlOW 


VALUE 


(11/70 


tfPQg  Tiae  required  to  prepare  full  date  7.5 

block 

CppK  Time  required  for  one  update  -of  the  3 

fli^t  plan  billboard 

tpi^  Time  requited  to  process  one  unit  33 

length  fli^t  plan  test  to  aircraft 
route  segments 

CgOP  Tine  required  for  handoff  nanageaent  10 

tficQ  Tine  required  to  generate  metering  500 

coanaod 

t)(g2  Tiae  required  to  insert  one  aircraft  100 

into  metering  schedule 

tpiQi  Time  required  for  progress  deviation  0.125 

check 

tppg  Tine  required  for  path  probe  2000 

tpi^g  Tine  required  for  path  resolution  8000 

tpgg  Tine  required  to  process  prior  sector  100 

data 

*’RTR  Time  required  per  target  to  prepare  0.2 

radar  message 

t-imy  Time  required  to  absorb  NAS  track  and  2 

and  store  AERA  track 

Cypg  Time  required  to  process  vertical  profile  1 

for  a  unit  length  flight 

Cyg])  Tine  required  to  process  wind  update 
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A.  2  MiacellMWOu*  Ter— 


TERM 


DBraHTIOR 


‘*C 

‘‘r 

di 

^FAC 

^PGC 

"c 

“P 


Pp 

"in 


Oiatance  of  fli|^C  chrou^  cteater 

Flitht  disconce  fron  present  peeicion  chcoagSi 
reneioder  of  center 

Sia  of  ell  cenCer  eirwey  discseices 

Free cion  of  eircreft  reaching  final  conflict  test 

Fraction  of  aircraft  reaching  groan  conflict  filter 

Itaiber  of  active  aircraft 

Munber  of  deviated  aircraft 

Ruaiber  of  state  segnents  coeitered  dvrins  conflict 
test  per  aircraft 

Percancage  of  active  aircraft  cIhU;  typicallj  have 
deviated 

Itanber  of  inbound  aircraft 


